Skip to content

Make layer_predict forward stored dots_list to predict() #358

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 11 commits into from
Jul 26, 2024

Conversation

brookslogan
Copy link
Contributor

Checklist

Please:

  • Make sure this PR is against "dev", not "main".
  • Request a review from one of the current epipredict main reviewers:
    dajmcdon.
  • Make sure to bump the version number in DESCRIPTION and NEWS.md.
    Always increment the patch version number (the third number), unless you are
    making a release PR from dev to main, in which case increment the minor
    version number (the second number).
  • Describe changes made in NEWS.md, making sure breaking changes
    (backwards-incompatible changes to the documented interface) are noted.
    Collect the changes under the next release number (e.g. if you are on
    0.7.2, then write your changes under the 0.8 heading).
  • Consider pinning the epiprocess version in the DESCRIPTION file if
    • You anticipate breaking changes in epiprocess soon
    • You want to co-develop features in epipredict and epiprocess

Change explanations for reviewer

This uses rlang::inject() to splat in the stored dots list. Some validation and tests have also been added, plus following @dajmcdon's suggested correction to an @inheritParams directive.

Magic GitHub syntax to mark associated Issue(s) as resolved when this is merged into the default branch

@brookslogan brookslogan requested a review from dajmcdon as a code owner July 9, 2024 22:11
@brookslogan brookslogan marked this pull request as draft July 9, 2024 23:52
We were missing `type` and `opts` in documentation because they weren't in the
signature of `predict.epi_workflow`, not because of an issue with
`predict.model_fit` docs, and it seems like the latter method is the one we'd be
directly using.
@brookslogan brookslogan marked this pull request as ready for review July 19, 2024 23:35
@brookslogan
Copy link
Contributor Author

@dajmcdon I addressed some comments but still have a few pending questions up above. The new changes might be worth a look... they don't seem too elegant as (i) they involve passing around type, opts, ... in many places but not everywhere, and (ii) because it's actually forwarding stuff in previously-unused ...; it was a quick and NSE-compatible way to do things, but I'm not sure we want to sacrifice parts of the dots "namespace" in so many places.

Copy link
Contributor

@dajmcdon dajmcdon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @brookslogan this all looks good to me. Feel free to merge.

Since epiprocess#472, as_epi_df.<decayed epi_df> will ignore the geo and time
type args and re-infer them, plus emit a warning if these args were provided. We
could `dplyr_reconstruct` to go back to trusting `meta` instead of re-inferring,
but since baking could plausibly (but likely rarely) change them, don't.

- Pre-epiprocess#472, this should be a bugfix in any such rare cases.
- Post-epiprocess#472, this should remove warning spam.
@brookslogan
Copy link
Contributor Author

@dajmcdon tests were failing due to an epiprocess update; I've slightly changed bake behavior in a way I think is a rare bugfix. Since bake-ing's pretty key, I'll leave it to you to merge.

@dajmcdon dajmcdon merged commit 63a520b into cmu-delphi:dev Jul 26, 2024
2 checks passed
@brookslogan brookslogan deleted the lcb/layer_predict-passing branch July 27, 2024 01:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow layer_predict() to pass along ...
2 participants